침해사고대응 기본 개요¶

2. Cyber Kill Chain¶

2.1. 사이버 킬 체인이란?¶

공격이 진행되는 과정을 단계별로 분석해서, 외부에서 발생하는 공격을 차단 및 대응하기 위해서 설계된 프레임워크입니다.
공격 라이프사이클(Attack Lifecycle)을 이해하는 과정이 필요하며, 다음과 같이 어떤 행위가 수행되었고 무엇이 탈취되었는지 등을 이해할 수 있습니다.

• 공격자가 어떻게 침투 했는지?
• 공격자가 네트워크 내부 어디까지 침투 했는지?
• 어떤 권한을 획득했고, 어떤 데이터에 접근할 수 있는지?

2.2. 사이버 킬 체인 단계¶

[참고 사항]
비선형적 공격 방식
- 공격자는 킬 체인 단계별로 진행하지 않으며, 공격 단계가 변경/반복될 수 있음
- 특정 단계 이후(내부망 침투 성공으로 가정), 내부망 정찰/정보 수집을 위해 첫 번째 단계로 돌아가는 등 반복적인 과정이 수행될 수 있음
대응 목표: 침해 사고 대응의 목적은 킬 체인 단계 중에서 가능한 한 초기 단계에서 공격을 탐지/차단 하는 것으로 알고 있음

3. MITRE ATT&CK 프레임워크¶

MITRE ATT&CK 프레임워크는 공격자의 행동을 이해하기 위한 프레임워크로, 특정 목표를 달성하기 위한 공격자의 전술/기술을 세분화하여 매트릭스 형태로 정리한 지식 베이스입니다.
Enterprise Matrix를 기반으로 기업용 IT 환경을 대상으로 실제 발생한 공격자의 행동을 문서화한 지식 베이스로, 공격자의 목표(전술-Tactics)와 목표 달성을 위한 방법(기술-Techniques)을 의미합니다.

• 프레임워크 링크: https://attack.mitre.org/matrices/enterprise/

1. 전술(Tactic)
   
   • 공격자가 달성하려는 궁극적인 목표
   • 초기 접근(Initial Access), 지속성 확보(Persistence), 권한 상승(Privilege Escalation) 등
2. 기술(Technique)
   
   • 공격자가 전술을 달성하기 위해 사용하는 구체적인 공격 방법
   • 사용 도구, 명령어 실행, API 등
   • T1105 - Ingress Tool Transfer: 공격자가 도구 다운로드에 사용하는 OS 내장도구(wget, curl 등)
3. 서브 기술(Sub-technique)
   
   • 특정 구현 방식이나 대상을 상세하게 다루는 기술 하위 항목
   • T1003.001 - OS Credentials: LASS Memory: 001과 같이 하위 항목으로 붙으며, 필요 권한 획득에 성공했을 때 LSASS 프로세스 메모리에서 자격증명 덤프하는 것을 의미
   • T1003.001(LSASS 메모리 덤프) 항목에 대한 공격을 탐지했다로 정밀 보고/대응

3.1. Pyramid of Pain¶

고통의 피라미드는 방어자가 다양한 유형의 공격을 탐지/차단했을 때, 공격자가 전술을 변경하는데 얼마나 많은 노력이 필요한지를 보여주는 것입니다.

1. 피라미드 바닥(Hash, IP, Doamin)
   
   • 공격에 대한 탐지/차단을 수행했을 때 공격자가 쉽게 변경할 수 있는 부분
   • 예시) 명령 및 제어(T1071) 시나리오에서 공격에 사용된 IP를 차단했을 때, 공격자는 새로운 C2 서버 또는 IP로 변경해서 다시 공격을 수행할 수 있으므로 공격 시간을 약간 늦추는 경우
2. 중간 단계(Network/Host Artifacts)
   
   • ATT&CK의 특정 기술 중에서 T1547.001 - 레지스트리 실행 키/시작 폴더와 대응되며, 이게 변경되면 공격자는 다른 방식의 공격을 수행해야 하는 상황 발생을 의미
3. 피라미드 꼭대기(TTPs)
   • 도구, 전술, 기술, 절차에 해당되며 MITRE ATT&CK의 핵심에 해당
   • PowerShell, Process Injection 등의 행위를 탐지/차단할 경우, 공격자는 침투 방식 자체를 변경해야 하는 상황을 의미

3.2. MITRE ATT&CK 매핑 예시¶

사고 조사 중 관찰된 공격자의 기술(Techniques)을 MITRE ATT&CK 프레임워크에 따라 매핑한 예시입니다.

3.3. Wazuh¶

엔드포인트 보안(EDR)과 보안 정보 이벤트 관리(SIEM) 기능을 통합한 오픈 소스 보안 플랫폼입니다.

4. 침해 사고 대응 프로세스 개요¶

사고 대응에도 여러 단계가 있는데 이를 침해 사고 대응 프로세스라고 정의합니다.
프로세스는 외부 공격에 의해 발생한 이벤트에 대해 준비 > 탐지 > 대응 할 수 있는 역량을 의미합니다.

• IT 보안 이벤트 대응 최적화
• 사이버 킬 체인 단계와 1:1 일치하지 않음

NIST에서 정의한 침해 사고 대응 프로세스는 4가지의 단계로 구성됩니다.
주로 준비와 탐지 및 분석 단계에서 악의적인 이벤트를 찾아내기 위해서 많은 시간을 사용하게 됩니다. 이벤트를 탐지하면 다음 단계로 넘어가서 이벤트에 대응하게 됩니다.

프로세스는 선형적이지 않고 순환적(Cyclic)이며 새로운 증거가 발견됨에 따라서 다음 단계로 변경될 수 있다는 점입니다. 프로세스 단계를 건너뛰지 않고, 다음 단계로 넘어가기 전에 현재 단계를 완료하는 것이 중요합니다.

예시: 감염된 기기 10대 발견 시, 5대만 격리하고 남은 5대는 감염된 상태로 둔 상황에서 제거 단계를 시작하는 것

• 비효율적인 사고 대응 방식
• 5대는 감염되었기에, 대응/추적하는 사실을 공격자에게 알리는 결과 초래

그렇기에 사고 대응은 크게 조사(Investigating)와 복구(Recovering)라는 두 가지 주요 활동으로 구분됩니다.

4.1. 조사(Investigation)의 목적¶

최초의 희생자를 발견하고 현재 진행 중인 사고의 타임라인을 작성합니다. 그리고 공격자가 어떤 도구와 악성코드를 사용했는지 파악합니다.
파악이 완료되면 침해된 시스템과 공격자가 수행한 행위를 문서화하여 기록합니다.

• Patient Zero: 보안에서는 악코드에 감염되거나 침해 당한 첫 번째 사용자 또는 기기를 지칭

4.2. 복구(Recovery)의 활동¶

침해사고 조사 이후에는 복구 계획을 수립하고 실행하는 활동으로 이어집니다. 계획이 실행되면 사고로 인해 중단이 발생했던 비즈니스는 정상 운영 상태로 복귀해야 합니다.
사고 처리가 완전히 완료되면 사고의 원인과 비용을 상세하게 기록한 보고서가 발행되며, 유사한 유형의 사고가 재발하는 것을 방지하기 위해 조직이 무엇을 해야 하는지 이해하기 위한 활동이 수행됩니다.

5. 준비 단계¶

준비 단계에서는 두 가지의 개별적인 목표가 있습니다.

1. 조직 내 침해사고 대응 역량 구축: 사고 발생 시 이를 처리할 수 있는 기반
2. IT 보안사고 예방 및 보호: 적절한 보호 조치를 구현해 사전에 사고를 차단하는 능력
   • 엔드포인트 및 서버 하드닝(Hardening)
   • Active Directory
   • MFA, PAM(Privileged Access Management)

*Hardening(하드닝): 시스템 취약점을 줄이고 공격 표면을 최소화하는 보안 강화 작업 의미

5.1. 준비 단계의 필수 요건¶

1. 사고 대응 인력: 조직 내부적으로 사고에 대응할 수 있는 역량과 이해도를 갖춘 인력
2. 교육된 인력: 보안 인식 제고 활동, 기타 교육 수단을 통해 가능한 전 직원이 보안 교육 이수
3. 정책 및 문서화: 사고 발생 시 지침이될 정책과 절차 정리
4. 소프트웨어 및 하드웨어 점검 도구: 사고 분석 및 대응에 필요한 장비와 소프트웨어 필요

5.2. 정책 및 문서화¶

사고대응을 수행하기 위해서는 정책/문서를 최신화하여 필요한 정보들이 포함되도록 해야합니다.

• 팀원들의 연락처 및 역할: 어떤 업무를 누가 담당하고 있는지 명시
• 관련 부서 및 외부 기관 연락처: 사고 대응과 관련있는 부서(IT, 법무, 컴플라이언스팀 등)와 외부 사고 대응 업체 등
• 사고 대응 정책, 계획 및 절차서: 사고 발생 시 따를 수 있는 공식적인 가이드라인
• 사고 정보 공유 정책/절차: 사고 대응/분석 정보들을 누구와 어떻게 공유할지에 대한 규정
• 네트워크 및 시스템 자산: 시스템 및 네트워크 정상 상태 정보, 네트워크 구성도, 전사 자산 관리 데이터베이스(IT자산 현황정보)
• 높은 권한의 계정: 사고가 발생했을 때 대응팀에서 즉시 사용할 수 있는 권한이 높은 계정이 필요하며, 사고가 확인되면 활성화하고 종료되면 비활성화하는 방식으로 사용
• 포렌식/조사 체크리스트: 어떤 항목들을 조사해야 하는지 알려주는 가이드

1. 법적대응 및 컴플라이언스
   심각하지 않은 사례일 경우 조직 내에서 마찰 없이 바로 처리될 수 있으나, 수사 기관 통보 또는 고객 및 외부 협력사와의 소통이 필요할 수 있습니다.
   • 사고로 인한 법적 문제 발생일 경우 더욱 문제가 될 수 있음

2. 기록 및 보고
   문서화된 지침도 중요하지만, 사고 조사를 진행하는 단계에서 사고 과정을 기록하는 것도 중요합니다. 사고가 발생한 상항에서 문제를 해결하는 데에 집중하기 때문에 과정들에 대해서 기록되지 않는 경우도 있습니다.

   • TimeStamp: 사건 및 활동이 발생한 시각
   • 수행한 활동
   • 활동 결과
   • 수행 주체

   결과적으로 육하원칙에 근거하여 문제를 해결하고 기록하는 과정이 필요합니다.

5.3. Tools¶

침해사고 업무를 수행하는데 있어서 필요한 도구는 다음과 같습니다.

• 디지털 포렌식 이미지 복제 및 분석 도구: FTK Imager
• 메모리 덤프 및 분석도구: Volatility
• Live Response 수집 및 분석도구: 가동 중인 시스템 데이터 수집 도구
• 로그 분석 도구
• 네트워크 패킷 수집/분석 도구 및 장비(케이블/스위치)
• Write BLockers: 쓰기 방지 장치로, 원본 데이터가 변조되지 않게 차단하는 장치 - Forensic
• 포렌식용 HDD, 물리적 장치 도구(드라이버 등), 침해지표(IOC), 암호화 소프트웨어 등

*Jump Bag: 위에서 언급한 도구들이 담겨있는 가방을 의미하며, 사고 발생 시 바로 사용할 수 있도록 준비되어야 한다.

*인프라 독립성: 침해사고는 "조직의 전체 도메인이 장악되었고 모든 시스템을 사용할 수 없게 될 수 있다"고 가정하여, 문서화 시스템을 독립적으로 사용하여 보안을 강화하는 것이 중요하다. 그리고, 이메일 및 통신 채널을 공격자가 보고있다고 가정하여 행동해야 한다. -> 실무에서 경험해보지 않았기에, 독립성이 완고하게 이루어져야 하는게 맞는지..?

준비 단계에서는 사고 예방도 중요하다. 대응팀의 직접적인 책임은 아니지만 어떤 보호 조치가 적용되어 있는지 알고 있어야 하며, 사고의 유형과 정교한 부분을 더 잘 파악할 수 있고 조사에 흔적/증거를 찾아낼 수도 있기 떄문이다.

5.4. DMARC(이메일 보안)¶

SPF와 DKIM을 기반으로 한 피싱 방어 메커니즘으로 조직을 사칭하는 이메일을 거부하는 방식입니다.

• 공격자가 직원으로 위장하여 송금 요청 메일을 전송할 경우, 시스템이 수신함에 도달하기 전에 차단
• 주의가 필요한 점: 설정이 잘 못 될 경우 정상적인 이메일까지 차단될 수 있기 때문에 구현에 주의가 필요

5.5. EndPoint 하드닝 및 EDR¶

공격의 주요 침투 경로에 활용되는 사용자 기기(워크스테이션, 노트북 등)에 대해서 다음과 같은 보안 조치가 필요합니다.

• LLMNR/NetBIOS 비활성화: 내부망 권한 탈취 공격 방어
• LAPS 도입: 로컬 관리자 비밀번호 자동 관리 및 일반 사용자 관리자 권한 제거
• PowerShell 제한: 제한된 모드(Constrained Language)로 설정하여 악성 스크립트 실행을 제한
• LOLBins 주의: 정상적인 시스템 파일을 악용하는 공격에 대한 모니터링 및 차단
• EDR 및 AMSI: 스크립트가 실행되기 전에 내용을 검사하는 AMSI(백신)와 연동되는 EDR 제품 선택
  • PowerShell을 사용할 수 있는 경우에는 AMSI를 우회할 수 있는 방법이 많기에, PowerShell 제한과 같이 사용하는 것이 효율적이라고 생각

5.6. Network Protection¶

내부망에 접근했을 때에는 동일한 네트워크 대역을 탐색하면서 조직 전체로 공격을 수행하게 됩니다. 이런 경우를 방지하기 위해서 네트워크를 분리해서 관리가 필요하며 핵심 시스템들은 격리하고 필요한 연결한 허용하는 방식이 필요합니다.

• IDS/IPS: 침입탐지/방지시스템 사용하며 외부에서 들어오는 IP주소만 확인하지 않고, 내부망에서 패킷의 실제 내용과 흐름을 확인해야 합니다.
  • 상태 기반 분석(Protocol Analysis): 예시로 웹 서비스(80,443)으로 RPC관련 명령어가 확인된다면 단순 웹 기능 접근이 아닌 명령어 실행으로 볼 수 있는 의심스러운 징후
  • SSL/TLS 복호화: IDS/IPS가 암호화된 데이터를 볼 수 없다면, 어떤 스크립트 및 코드가 숨겨져서 전송되는지 알 수 없기에 복호화를 통해 확인하는 과정 필수
• Access Control: 내부 네트워크에 연결될 때, 802.1x 또는 NAC에 등록된 기기만 접근할 수 있도록 제한
  • 인가되지 않은 기기가 유선 LAN을 꽂았을 때, 인증없이 접근할 수 없도록 설정
  • 접속 허용 전, 연결되는 PC의 백신 활성화 여부 및 최신 보안 패치 여부 확인

5.7. Privilege Identity Managerment / MFA / Password (권한 관리 및 인증)¶

Active Directory 환경에서 권한이 있는 계정의 정보를 탈취하는 것이 가장 흔하며 우선적으로 수행되는 기법입니다. Password1!와 같이 대소문자, 특수문자, 숫자가 포함된 비밀번호 정책에 맞지만 쉽게 유추할 수 있는 비밀번호에 해당되며 무작위 대입(Brute-Force) 공격에 취약합니다.

• PassPhrase: 비밀번호보다 "hello world ih처럼 긴 문자열을 사용한다면 무작위 대입 공격에는 효과적입니다. 단, 비밀번호를 기억하기 어려운 점도 있습니다.
• 다중 인증(MFA): 모든 관리자 권한의 계정/접속은 반드시 MFA를 적용해야 합니다. MFA만 적용하더라도 계정 탈취의 비율은 확연히 낮아진다고 보고 있습니다.

생각보다 많은 기업이 간단한 비밀번호를 사용하는 경우가 있어 관리자 계정을 탈취하기도 했습니다.

5.8. 취약점 스캔¶

자산에 대한 지속적인 취약점 스캐닝을 통해서 High, Critical 등급의 취약점은 즉시 조치하고, 그 외의 취약점은 영향력에 따라서 조치 계획을 수립해야 합니다. - 만약 패치 불가능한 취약점일 경우, 다른 방식으로 취약점을 막아낼 방법을 찾아야 합니다.

5.9. 보안 인식 교육¶

기업의 임직원 및 사용자를 대상으로 보안 인식 교육을 수행하여 정기적으로 해킹메일훈련, 피싱 등의 훈련을 통해서 보안 경각심을 높이는 방법도 고려해야 합니다.

5.10. Active Directory 보안 점검¶

공격자 관점에서 내부망을 바라보았을 때, AD를 대상으로 공격하는 경우가 있습니다. DC 권한을 탈취했을 때는 기업의 대부분의 정보를 열람/탈취할 수 있기 때문에 직접 점검하거나 외부 전문가를 통해서 정기적으로 점검하는 과정이 필요합니다. - AD에서는 사용자에서 관리자 권한을 획득할 수 있는 권한 상승 경로가 많이 있기에 더 유의해야 합니다.

5.11. Puple Team¶

실제 환경에서의 훈련을 통해서 사고 대응 실력을 유지할 수 있습니다. - 공격팀/방어팀이 협업하는 방식으로, 서로 간의 공격/방어 기법을 공유하는 과정을 통해서 탐지 규칙과 대응 절차를 개선해 나갈 수 있습니다.

6. 탐지 및 분석¶

해당 단계에서는 사고를 탐지하는 모든 측면이 포함되고 정보 및 지식 공유, 상황 기반의 위협 인텔리전스 활용도 이 단계에 포함됩니다.

외부 위협은 다양한 공격 경로를 통해 조직 내로 접근하며, 다음과 같은 방식을 통해 탐지할 수 있습니다. - 이상 징후를 발견한 사고대응팀 또는 직원 - 보안 도구 알림 (EDR, IDS, 방화벽, SIEM 등) - 위협 헌팅 (Threat Hunting) - 조직이 침해된 징후를 알려주는 제3자

네트워크에서는 다음과 같이 논리적인 분류로 단계별 탐지 체계 구축을 권장하게 됩니다. |분류|설명| |-|-| |네트워크 경계 탐지|방화벽, IDS/IPS, DMZ 등 활용| |내부 네트워크 수준 탐지|로컬 방화벽, 호스트 침입 탐지/방지 시스템 등 활용| |엔드포인트 수준 탐지|백신 프로그램(Antivirus), EDR 등 활용| |어플리케이션 수준 탐지|어플리케이션 및 서비스 로그 등 활용|

6.1. 초기 조사 (Initial Investigation)¶

보안 사고가 탐지되면 구성된 사고 대응팀이 초기 조사를 수행하고 어떤 이벤트가 탐지되었는지 전체 맥락(Context)을 파악해야 합니다.

[예시 시나리오] "관리자 계정이 특정 시간에 특정 IP 주소에 접속한 이력이 탐지된 경우" 시나리오에서 관리자가 접근한 시간 및 주소 등의 정보를 모른다면, 사건에 대해서 잘못된 결과가 만들어질 수 있습니다. 이 단계에서는 다음과 같은 정보들을 최대한 수집하는 것을 목표해야 합니다.

• 사고가 보고된 날짜 및 시간과 누가 사고를 탐지했고 보고했는지(최초 탐지/보고자)
• 어떻게 탐지되었는지? (대응팀 또는 보안장비 등 어떤 방식으로 탐지되었는지가 중요)
• 사건의 유형은 무엇인지? (피싱, 시스템 가용성 중단, 외부 공격 등)
• 영향받는 시스템 목록 (사고 발생 시 해당되는 경우)
• 시스템에 누가 접속했고, 어떤 조치가 취해졌는지 기록
• 의심스러운 활동이 지속중인지 중단되었는지 확인
• 물리적 위치, 운영체제, IP주소 및 호스트 이름, 시스템 상태 등
• IP 주소 목록
  • 악성코드가 추가로 탐지된 경우 유형, 시스템, 정보가 포함된 파일 및 데이터 추출

위와 같은 정보들을 수집해놓은 상태라면, 정보들을 기반으로 사고에 대해 의사결정하는데 조금의 시간을 단축할 수 있습니다.

6.1.1. 사고 타임라인 구축¶

위 정보를 바탕으로 사고 타임라인을 구축할 수 있으며, 타임라인은 사건 전체 기간 동안 발생한 일에 대한 전체 구조를 제공할 수 있습니다.
타임라인 이벤트는 발생한 시간 순서대로 정렬되지만, 이 순서에 맞춰서 증거가 발견되는 것은 아니라는 점을 유의해야 합니다.

• 증거 발생 시점 기준으로 정렬할 경우, 각각 개별 이벤트로부터 전체 맥락 파악 가능

또한 타임라인의 경우 새로운 증거가 발견되었을 때, 현재 사고의 일부인지 검증할 수 있습니다. 예시로 공격의 최초 페이로드로 생각했던 증거가 2주 전 다른 기기에서 동일하게 발견되었다면 상황이 달라지게 되며 각각의 다른 상황을 겪게될 수 있습니다.

• 발견된 증거가 지금의 증거와 매우 연관성이 높은 상황
• 발견된 증거가 현재의 증거와 무관하여 잘못된 곳을 조사하고 있는 상황

타임라인은 다음과 같은 항목이 포함되어야 하지만, 어떻게 항목을 지정하느냐에 따라서 다르게 작성될 수 있습니다.

타임라인은 주로 공격자의 행동에 초점을 맞추어 작성되기에 기록되는 활동들은 다음과 같은 정보들을 정확하게 기록하는 것이 중요합니다.

• 공격이 발생한 시점
• 시스템 접속을 위해 네트워크 연결이 수립된 시점
• 파일 다운로드된 시점

6.1.2. 사고 심각도 및 범위 확인¶

보안 사고를 처리할 때, 사고의 심각도와 범위를 파악하기 위해 다음과 같은 질문들에 대해서 답을 구해야 합니다.

1. 취약점 악용 시 영향력은 어느정도인지?
2. 취약점 악용을 위해 필요한 조건은 무엇인지?
3. 핵심 업무 시스템이 이번 사고의 영향을 받는지?
   • 영향받을 받는 시스템은 어느정도 인지? (정확한 대수 필요)
4. 제안된 복구 단계가 있는지?
5. 해당되는 취약점 또는 Exploit이 실제 유포되고 공격에 활용되고 있는지?
   • 스스로 전파되는 기능은 있는지?

영향력이 크거나 영향을 받는 시스템이 많을 수록 사고에 대해서는 즉각 처리 필요 및 보고 필요

6.1.3. 사고 기밀 유지¶

보안 사고의 경우 매우 민감한 정보이기 때문에 관련 법률 또는 경영진의 지시가 없다면 모든 정보들은 업무상 알아야 하는 인원에게만 제한적으로 공유가 되어야합니다.

• 공격자가 내부 직원일 가능성 존재
• 침해 사고 발생 시, 내/외부 이해관계자에 대한 공식적인 통보는 협의 후 지정된 담당자가 수행

침해사고 조사가 시작되면 기대치 및 목표를 설정하게 되며, 다음과 같은 내용이 포함됩니다.

• 발생한 사고의 유형
• 가용한 증거 소스
• 조사 소요 예상 시간

사고의 성격에 따라 공격자를 찾아낼 수 있는지에 대한 기대치도 설정하며, 새로운 단서가 발견됨에 따라서 내용은 변경될 수 있습니다.

주요 보안 용어 정리(Detection & Analysis)¶

실무 관점¶

1. 탐지 패러다임의 변화 (EDR & LOLBins) 최근 공격자들은 파일 형태의 악성코드를 심지 않고 LOLBins 기법을 사용하여 "흔적 없는 공격(Fileless Attack)"을 수행합니다.
   • 공격 흔적 최소화로 탐지/차단을 우회하고 지속성을 확보하기 위함
   • 파일 검사만 수행하는 AV(Antivirus)보다는, 정상 프로세스가 비정상적인 동작(예: 메모리 주입, 이상 네트워크 통신)을 하는지 감시하는 EDR의 도입과 모니터링이 필수적입니다.

6.2. 조사 과정(The Investigation)¶

침해사고 조사가 시작되면, 무슨 일이 일어났는지와 어떻게 일어났는지를 찾아내는 것입니다. 사고 데이터를 효율적으로 분석하는 과정이 필요하며 기술적인 지식과 경험을 갖추고 있어야 합니다.

사고가 어떻게 발생했으며, 무엇이 영향받았는지, 공격자가 어떻게 침입했는지, 어떤 도구를 활용했는지 등 공격 경로와 방법에 대해서 상세하게 분석해야 대응할 수 있으며 다시 발생하지 않도록 복구 계획을 세울 수 있습니다.

조사는 지금까지 파악한 정보가 담긴 초기 수집 데이터를 바탕으로 시작됩니다. 초기 데이터를 기반으로 조사가 진행되면서, 반복적으로 수행되는 3단계 순환 프로세스가 진행되며 다음과 같은 내용이 포함됩니다.

1. 침해 지표(IOC) 생성 및 활용
2. 새로운 단서 및 영향받은 시스템 식별
3. 2번으로부터 데이터 수집 및 분석

초기 조사 데이터(Initial Investigation Data)¶

결론 도달을 위해서는 조사 과정 전반에서 유효한 단서에 기반해야 합니다. 사고 대응팀에서 특정 발견 사항에만 매몰되지 않고 계속해서 새로운 단서를 찾아내야 합니다.

• 특정 활동만으로 조사할 경우 제한적인 결과 도출
• 조기 결론 및 불완전한 영향력

6.2.1. 침해 지표 생성 및 활용 (IOC)¶

침해 지표는 보안 사고가 발생했다는 징후를 의미하며, 침해 사고의 아티팩트(Artifact, 흔적)를 나타내고 구조화된 방식으로 기록됩니다.

• IOC 예시: IP주소, 파일 해시 값, 파일이름 등

IOC 조사에서 매우 중요하여 표준화된 방식으로 기록/공유하기 위해서 OpenIOC같은 전용 언어들이 개발되었습니다. 또 널리 사용되는 표준은 YARA가 있으며 Mandiant의 IOC Editor와 같이 IOC를 생성하거나 편집하는데 사용할 수 있는 무료 도구들도 있습니다.

• 오픈소스 도구: OpenIOC, YARA, IOC Editor
• STIX(Structured Threat Information eXpression): CISA에서 사용하는 IOC 형식
  • CTI(Cyber Threat Intelligence)를 일괄된 방식으로 사용하기 위한 직렬화 형식 사용(JSON)

IOC를 활용하려면 수집/검색 도구를 사용해야 하는데, 윈도우 환경에서는 기본적으로 WMI 또는 PowerShell을 활용합니다.

주의사항
침해된 시스템을 조사할 때는 높은 권한을 가진 사용자의 자격증명이 저장되지 않도록 해야합니다. 자격증명을 캐싱하지 않는 프로토콜 및 도구 활용(WinRM, 로그온 유형3, PsExec)

IOC를 활용해서 검색하게 되면, 동일한 침해 징후를 보이는 다른 시스템들이 탐지될 수 있습니다. 탐지된 내용들이 조사 중인 사고와 연관이 없을 수도 있기 때문에, 오탐(False Positives)을 식별하고 제거해야 합니다.

• 우선순위 조사 및 잠재적인 단서를 제공할 수 있는 시스템에 집중

IOC가 발견된 시스템을 식별했다면, 해당 시스템의 상태를 수집/보존해야 합니다. 가동 중인 시스템에서 즉시 데이터를 수집하는 라이브 대응(Live Response)를 수행하거나 시스템 종료 후에 분석을 진행할 수도 있습니다.

• 라이브 대응: 가장 일반적인 접근 방식으로 Artifact(흔적)가 그대로 있는 데이터셋을 미리 정의해서 수집
• 시스템 종료: Artifact(흔적)는 RAM에 존재하기 때문에 종료 시에 흔적이 사라질 수 있음(증거물 및 아티팩트 변조 방지를 위해 시스템과의 상호작용은 최소화)

위 과정으로 데이터 수집이 완료되면 분석 단계로 넘어가게 됩니다.
가장 많은 시간이 소요되는 프로세스로 Malware 분석 및 Disk 포렌식이 수행되며, 새로 발견된 단서들은 타임라인에 지속적으로 업데이트 됩니다.

• 메모리 포렌식: 지능형 공격을 다룰 때 매우 중요하며 점점 보편화 되고 있음

데이터 수집 과정 전반에서 중요한 점은 데이터가 법적 증거 능력을 갖출 수 있는 증거물 보관 연속성 관리가 필요

6.2.2. 위협 탐지에서의 AI 활용¶

인공지능을 이용해서 보안 사고 탐지 및 우선순위(Triage) 결정, 대응하는 방식으로 변화하고 있습니다. 침해 사고 대응(IR) 워크플로우에서는 로그, 경보, 보고서를 수동 검토해왔지만, 분석하는 과정들을 AI로 자동화하게 됨에 따라서 보다 빠르게 행위 이상 징후를 식별해 대응 시간을 단축하고 정확도가 높아지고 있다고 합니다.

• Elastic Security의 Attack Discovery 기능: 생성형 AI를 사용한 수천 개의 탐지 이벤트 분석/요약 구성
• MITRA ATT&CK 매핑 정보도 함께 제공

AI를 이용해 침해 사고 대응의 다른 영역에서도 다음과 같이 활용할 수 있습니다.

• 보안 사고 대응 프로세스에서 반복적인 작업 자동화 및 대응 속도 향상

6.3. 조사 후 단계(봉쇄, 복구)¶

조사가 완료되면 수집된 단서와 타임라인에 정리된 정보를 바탕으로 사고가 추가적으로 발생하지 않도록 봉쇄 단계를 진행합니다.

1. 봉쇄(Containment)
   • 사고의 확산 방지/추가 피해 차단

2. 흔적 제거(Eradication) 사고의 근본 원인(Root Cause)과 공격자의 흔적 제거

   • 취약점 제거: 공격에 활용된 취약한 서비스 종료 및 긴급 보안 패치 완료
   • 악성 요소 제거: 탐지된 맬웨어 삭제, 공격자가 생성한 백도어 계정 및 스크립트 제거
   • 시스템 재구축: 오염된 시스템을 백업에서 복원하거나 OS부터 완전히 새로 설치
   • 보안 강화(Hardening): 사고가 발생한 시스템 외에도 네트워크 전반에 걸쳐 유사 보안 설정 강화

3. 복구 (Recovery) 사고가 발생했던 시스템들을 운영 환경으로 복귀시키고 정상 서비스 재개
   복구된 시스템들은 사고 후에 집중적인 로깅 및 모니터링 대상이 됩니다. 공격자들의 타겟이 되었었고 이미 침해 사고가 발생했던 시스템이기에 다시 접근할 가능성이 높기 때문입니다. 그렇기에 주의 깊게 봐야할 이벤트는 다음과 같습니다.

   • 비정상 로그온: 기존에 사용 이력이 없는 계정이나 서비스 계정의 갑작스러운 접속
   • 비정상 프로세스: 알 수 없는 이름의 프로세스 실행 및 리소스 급증
   • 레지스트리 변동: 맬웨어가 주로 이용하는 자동 실행(Auto-run) 경로 등의 변경

6.4. 사후 활동¶

사고 기록 및 역량을 향상시키는 단계이며 사고 처리에 참여한 모든 이해관계자가 모이는 회의에서 수집/분석하는 것이 좋으며 사고보고서 마무리 후 단계에서 진행됩니다.

최종 보고서는 전체 프로세스에서 중요한 부분으로 다음과 같은 내용이 포함되어야 합니다.¶

• 무슨 일이 언제 일어났는가?
• 사고 대응 계획, 플레이북, 정책 및 절차에 따라 팀이 사고를 얼마나 잘 처리했는가?
• 조속한 사고 처리를 돕기 위해 비즈니스 부서에서 필요한 정보를 제공하고 신속하게 대응했는가? 개선할 점은 무엇인가?
• 사고를 봉쇄하고 박멸하기 위해 어떤 조치들이 시행되었는가?
• 향후 유사한 사고를 방지하기 위해 어떤 예방 조치를 마련해야 하는가?
• 향후 유사한 사고를 탐지하고 분석하는 데 어떤 도구와 자원이 필요한가?

팀은 사고 대응 계획, 플레이북, 정책 및 절차를 업데이트할 필요가 있는지도 확인해야 하며, 사고 후 활동 단계에서는 문서화와 프로세스 측면, 도구, 교육 상태, 준비성 및 전반적인 팀 구조를 재평가하는 것이 중요합니다.